A memory leak is a major threat to reliability which is a key indication of software system quality. The memory leak can degrade system performance and even result in system failure when serious.
Memory space required by many variables cannot be determined in compiling the software. Therefore, the operating system is configured to allocate memory dynamically to these variables at runtime. Accordingly, many programming languages have their own memory management mechanisms so that the memory is allocated for a variable when being created and reclaimed when the variable no longer needs the memory.
Inappropriate programming in a program may lead to memory leak which exhibits differently among various kinds of programs. For instance, in a C/C++ program, a memory leak means the dynamically allocated memory is unrelieved or cannot be relieved for some reason which results in waste of system memory. While in a Java program, reclamation of memory is automatically managed by GC (Garbage Collection) without the need of the programmer relieving memory through explicit operations. However, there exists the possibility of a memory leak in a Java program since GC can only reclaim the memory spaces used by the objects which are not referenced by other objects. This means when a program inadvertently maintains references to objects that it no longer needs then the garbage collector is prevented from reclaiming space which results in a memory leak.
For example, in a Java program, objects are requested circularly and the requested objects are put into a vector. When an object is being relieved, i.e. the object is set to null, an object exhibits un-collectable by GC since the vector still refers to the object. Therefore, an object must be removed from the vector if the object is put into the vector. The simplest way is to remove the object from vector using a remove method but is not always done. This is a major reason for which memory leak occurs in a Java program.
As another example, Class Logger has a static variable temp of Class HashMap. Every time Logger.log(message) is executed, the value of the message is written into temp (with keys of current thread+current time), and then items with keys of a current thread and a current time are removed from temp before exit. It is noted that the current time here is varying, so the deletion of items before the exit of the method log cannot remove the initially written items. Thus, any character string transferred to the log as a parameter is referenced by the static variable temp of Logger so that this string cannot be garbage collected. Keeping such object reference creates a Java memory leak.
A major reason for memory leak in a Java program is retaining these no longer used object references. In simple, inappropriate programming leads to the presence of a reference chain which should be absent. As such objects referred to cannot be reclaimed. Hence for a Java program, the objective of memory leak analysis is to find out these useless reference chains and reason they were formed.
In prior memory leak analysis of a program, there are two types of solutions (1) static analysis methods and (2) dynamic analysis methods. Dynamic analysis methods find memory leak problems by profiling the memory or stack activity at runtime. However for a Java program, dynamic analysis methods such as LeakBot, described in “An Automated and Lightweight Tool for Diagnosing Memory Leaks in Large Java Applications”, Nick Mitchell, and Gary Sevitsky, European Conference on Object-oriented Computing (ECOOP), July 2003, cannot directly link memory leaks to Java source code and requires developers' extra efforts to identify the locations in the source code. Static analysis methods use program analysis technologies to analyze the source code. For example refer to the memory analysis methods disclosed in “Automatic removal of array memory leaks in Java”, R. Shaham et al., In D. A. Watt, editor, Compiler Construction, 9th International Conference, volume 1781 of Lecture Notes in Computer Science, pages 50-66, Berlin, Germany, March 2000, Springer and “Low-overhead memory leak detection using adaptive statistical profiling”, T Chilimbi, and M. Hauswirth, In Proceedings of the Symposium on Architectural Support for Programming Languages and Operating Systems (ASPLOS), October 2004. However, such static analysis methods have high computation overhead which results in a long time to locate memory leak items.
In Micheal D. Ernstan's article titled “Static and dynamic analysis: synergy and duality”, ICSE Workshop on Dynamic Analysis (WODA), Portland, Oreg., USA, May 2003, an idea of combining dynamic analysis method and static analysis method to analyze software was proposed. However, there is no concrete solution to the analysis problem.
Therefore, it is desirable to provide a method and apparatus capable of locating memory leak items accurately in a short time.